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Remarks/ Arguments 

The Applicant thanks the Rxaminer for the interview of October 2, 2007. 

During ihe interview, the Examiner suggested that the Applicant submit a further 
paper setting forth the basis for the patentability of claim 7 over the art of record, 
intimating that this will likely lead to withdrawal of the finality of the office action. The 
Examiner also requested a further description of FIG. 4. This response is motivated by 
the Examiner's suggestion and request. 

1. Cl aims 7-12 Not Obvious under 35 U.S . C. S 1 0300 

Claim 7 is set forth below for convenience. As requested by the Examiner, the 
Applicant has indicated (embedded in square brackets below) where support for the 
various claim limitations may be found in the application as filed. 

Claim 7 (Previously presented): A wireless mobile device 110, FIG. 1] comprising: 
a processor f 12, FIG. 1]; 

computer readable memory in communication with said processor [1 6* FIG. 1], 

storing virtual machine software [24, FIGS. 1 and 2] controlling operation of said 

wjrcloss mobile device, 

said virtual machine software comprising: 

a parser [61 5 FTG. 2} for receiving a text file [para. 93J; 
a screen generation engine [67, FIG. 2], for presenting at least one screen at 
said wireless mobile device in accordance with said text file [paras. 95-981; 
an event handler [65, FIG. 2] tor processing events arising in response to 
interaction with said at least one screen in accordance with said text file 
[paras. 101, J 02]; 
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object classes [69, FFG. 2; para. 391 corresponding to actions to be Liken by 
said wireless mobile device in response to interaction with said at least one 
screen [para. 40 j; 

an objed class [69, FIG. 2; para. 39J corresponding to a data table for storing 

data at said wireless mobile device [para. 41 ; FTGS. 161, 1 6JJ; and 

an object class [69, FIG. 2; para. 39] corresponding to a network message to 

be received or transmitted by said wireless mobile device [para. 41; FIGS. 

16K,16M1. 



In the Final Office Action, the Examiner rejected claim 7, as well as all of the 
other claws in the application, under 35 TLS.C. § 103(a) as unpatentable over U.S. Patent 
7,051>080B1 to Paul in view of U,S. Patent 7,010,573 Bl to Saulpaugh et ah 

The Applicant strenuously traverses this rejection on _the basis that no prima fac ie 
case of obvious n ess has been established for claim 7 The reason is twofold; (a) the prior 
art references do not leach or suggest all of the claim limitations; and (b) there is no 
suggestion or motivation to modify the references or combine reference teachings in the 
manner suggested by the Examiner. 



(a) Prior Art References Do Not Teach or Suggest all of the Limitations of Claim 7 

As discussed during the Examiner interview, the cited references simply do not 
teach at least the following limitations of claim 7: 

(i) a wireless mobile device comprising: . . . computer readable memory in 
communication with said processor, storing virtual machine software ... 
comprising: a parser ftvr receiving a text file : 
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a wireless mobile device comprising: ... computer readable memory in 
communication with said processor, storing virtual machine software ... 
comprising: 4 , , a screen g e neration engine , for presenting at least one 
screen at said wireless mobile device in accordance with said text file; 

a wireless mobile device comprising: ... computer readable memory in 
communication with said processor, storing virtual, machine software ... 
comprising: . . . object classes cor responding to actions to be taken bv sai d 
wireless mobile device in response to interaction with said at least one 
screen; 

a wireless mobile device comprising: ... computer readable memory in 
communication with said processor, storing virtual machine software ... 
comprising; . . . aiL^bi ect class corresponding to a data tabic for storing 
data at said wireless mobile device; or 

a wireless mobile device comprising: ... computer readable memory in 
communication with said processor, storing virtual machine software ... 
comprising: . . . an object class corresponding to a network message to be 
received or transmitted by said wireless mobile device. 
[Emphasis addedj 

The language "a wireless mobile device comprising: computer readable 
memory in communication with said processor, storing virtual machine software 
comprising:" is reproduced in each of (i) to (v) above, as a reminder that claim 7 is 
directed to a wireless mobile device, and in particular, to a wireless mobile device 
comprising a computer readable memory storing virtual machine soflwnre comprising the 
various features of paragraphs (i) to (v). 

Fundamentally, the Examiner's reliance upon the purported disclosure by Paul at 
Fig. I, #1 10 of a processor and computer readable memory in communication with said 
processor storing virtual machine software control ling operation of a mobile device (at 
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Fig. 1, #101) is Hawed. The i-eason, as emphasized during the Examiner interview, is that 
reference numeral 1 10 ofPaul does not refer to a wireless mobile device, but rather refers 
to a mobile applications server (5:26-32) that is separate from mobile device #101 of 
Paul. 

Accordingly, limitation (i) above is simply not disclosed by Paul Fig. 1 , #1 12, 
since reference numeral 112 of Paul does not form part of mobile device 1Q[ . Rather, 
#1 12 refers to a portion of the separate mobile applications server 110 (8:21-22). 

Similarly, limitation (ii) above is not disclosed by Paul 6:63-67 and 7:1-10 as the 
Examiner suggests, since the applications 1 16 referenced in thai passage are executed at 
the mobile applications server 110 (6:33-14), not at the mobile device 101. 

With respect to the remaining limitations (iii), (iv) and (iv) above, the Examiner 
suggests at page 5 of the Office Action that the limitations are disclosed in Saulpaugh et 
al. at 21:40-67 as "message gate code". However, the cited portion of Saulpaugh et al. 
reveals nothing as to the composition of "message gate code." Moreover, the Applicant 
can sec no basis lor concluding that "message gate code" inherently includes the above- 
noted claim elements. Accordingly, it is submitted that limitations (iii) to (v) are not 
taught or suggested by any of the cited references. To the extent that the Exuminer 
disagrees, the Applicant expressly re quests clarification from the F.xamin«> r as to the 
columns and lines in Saulpaugh et al. unon which the c onclusion that "message pate 
code'' inherently includes the above-noted claim limitations is based , 

(b) Lack of Suggestion or Motivation To Modify References or Combine Reference 
Teachings to arrive at Claim 7 

In subsection (a) above, the Applicant sets forth its basis for concluding that claim 
limitations (iii) to (v) arc not disclosed in Saulpaugh et al. 
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Even if the above-noled claim limitations were disclosed in Saulpaugh et al., 
however, the Applicant submits that one of ordinary skill in the art would not combine 
them with Paul, as the Examiner suggests, because doing so would be contrary to the 
approach of the Paul reference. 

As understood by the Applicant, the strategy of Pan] is to implement the possibly 
complex logic that determines screen content at the mobile applications server HO (Paul 
7:11-26), not at the mobile device 101, The rationale for this approach (as detailed at 
page 4 of the previous office action response) is to permit mobile device 101 t o act as a 
"dumb device" that merely displays the pages sent to it by the server 110 and reports 
back any keys pressed by the user (4:19-23; 9:63-10:2). In line with this approach, an 
objective of Paul appears to be to avoid unnecessarily occupying the limited memory of 
the mobile device (see Paul abstract, last sentence). 

Given this model of operation, a person of ordinary skill would not odd the 
various claimed object classes (as purportedly disclosed by Saulpaugh et al.) to the 
mobile device, since this would not only fail to contribute to the "page by page" 
navigation approach of Paul, but would also unnecessarily occupy the limited memory at 
the mobile device, contrary to the slated rationale of Paul. 

(c) Conclusion 

For all of the above reasons, the Applicant submits that a prima facie case of 
obviousness has not been made in respect of claim 7. Withdrawal of the rejection of this 
claim, and all claims dependent therefrom (i.e. claims 8-12), is therefore respectfully 
requested. 



2. Claims 1-6, 13-16Not Obvious under 35 U.S.C. $103fa) 

The Applicant's arguments regarding the patentability of the remaining claims of 
the present application (i.e. claims 1-6 and 13-16), as made at pages 3-6 of Che previous 
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Office Action response dated April 16, 2007, are maintained. For convenience, these 
arguments are reproduced below. 

To establish a prima facie case of obviousness, three criteria must be met. First 
there must be some suggestion or motivation, cither in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference 
or to combine reference teachings. Second, there must be a reasonable expectation of 
success. Finally, the prior art reference (or references when combined) must teach or 
suggest all the claim limitations. The teaching or suggestion to make the claimed 
invention and the reasonable expectation of success must both be found in the prior art, 
and not based on applicant's disclosure. MPEP § 2142. 

The Applicant submits that Lhe prima facie case of obviousness has not been 
established for claims 1-6 and 13-16 because there is no suggestion or motivation to 
modify the references or combine reference teachings in the manner suggested by the 
Examiner. 

At page 3 of the Office Action, Examiner states, in respect of claim 1 , that Paul 
fails to explicitly teach a representation of a text file defining: a format of network 
messages for exchange of data generated by said application, but suggests that this claim 
feature is disclosed in Saulpaugh ct al. The Examiner states that it would have been 
obvious to one of ordinary skill in the art at the time invention was made to combine the 
teachings of the cited references "to provide a representation of a text file defining a 
format of network messages for exchange of data as disclosed by Saulpaugh et al. 
because it would enable the mobile device capable of communicating among network 
clients and services." 

In response, the Applicant submits that one of ordinary skill In the art would noj. 
combine the references as suggested, as doing so would be entirely contrary to the 
approach of the Paul reference. Moreover, because combining the references would 
needlessly increase wireless network traffic and possibly increase transmission costs, the 
suggested combination would be avoided. 
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Paul is understood to be concerned with making network-based services readily 
available to a wide range of mobile devices, which may have limited resources (sec Paul, 
3:34-47). In the exemplary system disclosed by Paul, a mobile applications server 110 
hosts one or more applications 116 that can be accessed by a mobile device 101 by way 
of a network 308 and wireless link 106 (see Paid. 5:57-59 and FIG. 1A). The 
applications 1 1 6 communicate indirectly with the mobile device through an intermediary 
mobile interactions server 1 50, which generates data, e.g. in the form of a textual, markup 
language document, that describes one or more graphical elements (a "page") for display 
on Lhe screen of the mobile devices (see 7:39-42, 9:53-57; 32:12-21). The A pplicant can 
find no evidence that any other type of information is transmitted to the mobile device 
101. Accordingly, the markup language document received by the mobile device is 
xmderstood to contain only g raphical element/page inform ation. This is Consistent with 
Paul's strategy of implementing the (possibly complex) logic that determines mobile 
device "page" content at the mobile applications server 11 0 rather than at the mobile 
device (7:11-26). This is understood to permit mobile device 101 to act as a "dumb 
device" which merely displays the pages sent to it by the server 110 and reports back any 
keys pressed by the user (4:19-23; 9:63-10:2). The screen content that is sent to the 
mobile device 101 is sent in a known format, such as HDML, VoxMT. or WML (9:20- 
27). This is advantageous because mobile devices may be preprogrammed to be able to 
understand these formats. 

Given this operation, it would be illogical for Paul to be combined with any 
reference that suggests that the textual document received by the mobile device should 
contain, in addition to screen layout and content information, "a format of network 
messages for exchange of data generated by said application". The reason is that Paul 
already uses "markup languages tailored to types of mobile devices", such as HDML, 
VoxML or WML (which the devices already understand), for this purpose (9:20-23). 

The Examiner's attention is drawn to term "said application" in the relevant 
portion of claim 1 ("a fonnat of network messages for exchange of data generated by said 
application" [emphasis added]). The point is this: what is at issue here is got the 
exchange of data generated by any. application, but rather the exchange of data generated 
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by said application, i.e. the application executing at a computing device whose data is 
presented at a remote wireless device. Ft is clear that the Examiner considers application 
116 (sec Paul 6:53-57, as died by the Examiner) to be the "application" of claim 1. So 
what is at issue is. whether Saulpaugh et al. suggests receiving, at the wireless device, a 
representation of a text file def ining a format of network messages for exchange of data 
generated by application 1 16 of Paul. As noted above, Paul already has an approach for 
presenting that application 1 16 at the wireless device: it uses "markup languages tailored 
to types of mobile devices** for this purpose. The introduction of a new message format 
is therefore unnecessary. 

Based on the foregoing, it is clear that inclusion of message format definitions in 
a text document received by the mobile device 101 of Paul would be wasteful of device 
resources (e.g. memory), because the definitions arc not needed by the mobile device in 
order to present application data. Moreover, the unnecessarily included message format 
descriptions would needlessly consume wireless bandwidth when the text document is 
transmitted to the wireless device. This may disadvantageously increase costs in the case 
where a service provider charges for wireless service based on the amount of data 
transmitted. 

For all of these reasons, the Applicant submits that one of ordinary skill in the art 
would not combine the references as the Examiner suggests. Accordingly, the Applicant 
submits that a prima facie case of obviousness has not been made in respect of claim I, 
Withdrawal of the rejection of this claim, and all claims dependent therefrom (i.e* claims 
2-6), is therefore respectfully requested. As well, withdrawal of the rejection of claim 13, 
which was rejected for the same reasons as claim 1, and claims 14-16 depending 
therefrom, is also requested, on the same grounds. 

3. Furt he r Description of FTP, 4 

During the interview of October 2, 2007, the Examiner requested a further 
description of FIG. 4, ostensibly to assist the Examiner with possible further searching. 
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As described in the published application, e.g., at paragraph 49, FIG. 4 illustrates 
an exemplary XML application definition tile 28 having three components. 

The first component is a user interface definition section 48. The user interface 
section 48 may be used to define various screens having buttons, menus, checkboxes, and 
other user interface items (sec paras. 52-63) as well as events associated with user 
interface items and actions thaL should be performed when Ihe events occur (see, e.g., 
paras. 64 and 65; see also FIG. 16U at section 5,2.3,2 and FIGS. 9 and 10). This section 
defines the format of each screen and how the user interacts with them (see para. 49). 
The intent is for virtual machine software at the mobile device to process this section as 
described at paras. 95-98 and FIGS. 8-9 in order to create and display screens at run time. 

The second component is a network transactions definition section 50. This 
section defines the format of data to be. exchanged with the server-based application at 
run time (see para, 49; see also the message 94 described in para. 118 and shown in FIG. 
14), This may include defining an update that is performed to a table in the device's 
local storage in association with a message (see para. 67; see also below). 

The third component is a local data definition section 52 defining the format of 
data to be stored locally on the mobile device, i.e. a logical database that may be stored at 
the mobile device (see paras. 49 and 69). Database tables having fields and attributes 
within the tables may be defined (see paras. 70, 71), 

4. Ab stract in Acceptable Form 

During the interview, the Applicant's agent requested that the objection to the 
abstract be withdrawn on the basis that the abstract as amended is free of legal 
phraseology such as "means" and "said". This request is hereby reasserted. 
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5. ClQ^inft 

Based on the foregoing, it is believed thai the present application is in allowable 
form. Early favorable reconsideration of the application is therefore earnestly solicited, 

Please note the new attorney docket number of 93422-45 for this application. 

If any issues arisc > or if the Examiner has any suggestions for expediting 
allowance of this application, the Applicant respectfully invites the Examiner to contact 
the undersigned at the telephone number indicated below. 

The Commissioner is hereby authorized to charge any additional fees connected 
with this communication or credit any overpayment to our Deposit Account No. 1 9-2548. 



Respectfully submitted, 




SMART & BIGGAR 

438 University Avenue 
Suite 1500, Box 111 
Toronto, Ontario 
Canada MSG 2K8 
Telephone: (416) 593-5514 
Facsimile: (416) 591*1690 



Date: October 1.2, 2007 
PAE/jb5 93422-45 
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